Ch. 9 Statistical Modeling and KnitR
Rose An, Michael Krzywicki
2025-10-27
1 Introduction
In this tutorial, we will learn how to set up a R Markdown document for reproducible statistical analysis/modeling, primarily using functions and syntax from the KnitR package. On Tuesday, we will ensure that everyone has downloaded the right data and packages and go over code chunk setup and begin analysis?. On Thursday, we will learn different ways to source and code analysis chunks, how to ensure your analysis is reproducibly random, and how to efficiently run computationally-intensive analysis.
1.1 Aim
We will learn how to dynamically connect data gathering and source code to markdown documents, setup pipelines to rerun analysis and present results whenever compiled, and keep markdown documents up to date and reflecting changes made to the data or analysis in source code files.
1.2 Why is it important?
Coding is hard. It takes a long time, and you’ll likely have to go back to the same analysis multiple times to tweak and change things. It is important to setup a good workflow early to ensure you’re not scrambling to make your research reproducible at the end of the process. You’ll be saving yourself a lot of time if your analysis is reproducible and your results presented every time you knit your document.
2 Learning Outcomes
Through this tutorial, students will learn to:
- Set up a chunk’s outputs correctly.
- Dynamically report variables in text.
- Source or code analysis through multiple methods.
- Ensure results are reproducibly random.
- Run computationally intensive analysis efficiently.
3 Packages
Make sure you have the following packages: “knitr”, “rmarkdown”, “bookdown”, “formattable”, “kableExtra”, “dplyr”, “magrittr”, “prettydoc”, “htmltools”, “knitcitations”, “bibtex”, “devtools”, “tidyverse” Not sure we’ll actually need all this. Below are the code chunks for loading packages and setting up the document from
###~~~
# Load R packages
###~~~
#Create a vector w/ the required R packages
# --> If you have a new dependency, don't forget to add it in this vector
pkg <- c("knitr", "rmarkdown", "bookdown", "formattable", "kableExtra", "dplyr", "magrittr", "prettydoc", "htmltools", "knitcitations", "bibtex", "devtools", "tidyverse")
##~~~
#2. Check if pkg are already installed on your computer
##~~~
print("Check if packages are installed")
#This line below outputs a list of packages that are not installed. Which ones of the packages above are installed in computer, print packages that are not installed. Should print 0.
new.pkg <- pkg[!(pkg %in% installed.packages())]
##~~~
#3. Install missing packages
##~~~
# Use an if/else statement to check whether packages have to be installed
# WARNING: If your target R package is not deposited on CRAN then you need to adjust code/function
if(length(new.pkg) > 0){
print(paste("Install missing package(s):", new.pkg, sep=' '))
install.packages(new.pkg, dependencies = TRUE)
}else{
print("All packages are already installed!")
}
##~~~
#4. Load all required packages
##~~~
print("Load packages and return status")
#Here we use the sapply() function to require all the packages
# To know more about the function type ?sapply() in R console
# Just an easier way to load all packages
sapply(pkg, require, character.only = TRUE)## Loading required package: knitr## Loading required package: rmarkdown## Loading required package: bookdown## Loading required package: formattable## Loading required package: kableExtra## Loading required package: dplyr##
## Attaching package: 'dplyr'## The following object is masked from 'package:kableExtra':
##
## group_rows## The following objects are masked from 'package:stats':
##
## filter, lag## The following objects are masked from 'package:base':
##
## intersect, setdiff, setequal, union## Loading required package: magrittr## Loading required package: prettydoc## Loading required package: htmltools## Loading required package: knitcitations## Loading required package: bibtex## Loading required package: devtools## Loading required package: usethis## Loading required package: tidyverse## ── Attaching core tidyverse packages ──────────────────────── tidyverse 2.0.0 ──
## ✔ forcats 1.0.0 ✔ readr 2.1.5
## ✔ ggplot2 3.5.1 ✔ stringr 1.5.1
## ✔ lubridate 1.9.3 ✔ tibble 3.2.1
## ✔ purrr 1.0.2 ✔ tidyr 1.3.1
## ── Conflicts ────────────────────────────────────────── tidyverse_conflicts() ──
## ✖ tidyr::extract() masks magrittr::extract()
## ✖ dplyr::filter() masks stats::filter()
## ✖ dplyr::group_rows() masks kableExtra::group_rows()
## ✖ dplyr::lag() masks stats::lag()
## ✖ purrr::set_names() masks magrittr::set_names()
## ℹ Use the conflicted package (<http://conflicted.r-lib.org/>) to force all conflicts to become errors# debug = right-pointing arrow next to code will load in console so you can go line by line and debug. pressing this also seemed to resolve the CRAN needs a mirror error
# Generate BibTex citation file for all loaded R packages
# used to produce report Notice the syntax used here to
# call the function
knitr::write_bib(.packages(), file = "packages.bib")
# The .packages() function returns invisibly the names of all packages loaded in the current R session (to see the output, use .packages(all.available = TRUE)). This ensures that all packages used in your code will have their citation entries written to the .bib file. This packages is then used in the Appendix to cite the code used4 Data
Download data from google drive. For this chapter, we will be working with a couple of datasets. Mike is working on consolidating some different exploratory analyses he did at different times over the last year. He wants to get them in the same place and make sure that they are reproducible. We’ll start with a dataset of “encounter rates” calculated from eBird data, which are calculated as the percentage of checklists that include a particular species in a given area (Schuetz and Johnston, 2019). This data has been analyzed for the United States by state, and Mike is getting ready to do encounter rates for species in Sonora, Mexico that are also found in Idaho. Before digging into the eBird data for Sonora, Mike wanted to get to know the dataset for Idaho so that he knows what species to look for in the Sonora data. Let’s get that data ready.
#Load Data
library(tidyverse)
#load csv file of data
state_enc_rate <- read.csv("state.level.enc.rate.csv")
view(state_enc_rate)
#Get rid of uneccessary columns
state_enc_rate_clean <- state_enc_rate %>%
select(
-query.volume.state #not needed for analysis
)
view(state_enc_rate_clean)
#filter to just Idaho
state_enc_rate_clean_filtered <- state_enc_rate_clean %>%
filter(
state == "Idaho",
)
view(state_enc_rate_clean_filtered)
#get rid of species with no encounter rate
ID_enc_rate <- state_enc_rate_clean_filtered %>%
filter(encounter.state.normalized!=0
)
#get ride of encounter rates below 50 to focus on "commonly encou
ID_enc_rate <- ID_enc_rate %>%
filter(encounter.state.normalized > 50)
view(ID_enc_rate)Setup Chunk Options:
### Chunk options: see http://yihui.name/knitr/options/ ###
### Text output
opts_chunk$set(echo = TRUE, warning = TRUE, message = TRUE, include = TRUE)
## Code formatting
opts_chunk$set(tidy = TRUE, tidy.opts = list(blank = FALSE, width.cutoff = 60),
highlight = TRUE)
## Code caching
opts_chunk$set(cache = 2, cache.path = "cache/")
## Plot output The first dev is the master for the output
## document
opts_chunk$set(fig.path = "Figures_MS/", dev = c("png", "pdf"),
dpi = 300)
## Figure positioning
opts_chunk$set(fig.pos = "H")5 Identify the correct chunk commands to use in different situations.
Although dynamically linking source code to markdown documents is the main goal of this chapter, sometimes it makes sense to include short code chunks directly into your markdown document. There are a variety of customizable options on how the code and its output are display in the final knitted document. We use code chunk arguments from the knitr package to choose the parts of our code chunks that are outputted in the final html document.
#Load Data
First we are going to to do a little bit more data transformation to make a couple of objects of the Idaho encounter rate data grouped taxonomically for some descriptive statistics we will use later.
# Pull passerines from ID encounter rates list
passerine_enc_rate <- ID_enc_rate %>%
filter(common.name %in% c("American robin", "bank swallow",
"black-billed magpie", "black-headed grosbeak", "Brewer's blackbird",
"Bullock's oriole", "Cassin's finch", "Cassin's vireo",
"cedar waxwing", "cliff swallow", "dark-eyed junco",
"dusky flycatcher", "European starling", "evening grosbeak",
"Hammond's flycatcher", "house finch", "lazuli bunting",
"MacGillivray's warbler", "mountain chickadee", "northern rough-winged swallow",
"olive-sided flycatcher", "pine siskin", "red crossbill",
"red-winged blackbird", "sage thrasher", "song sparrow",
"western kingbird", "western tanager", "western wood-pewee",
"willow flycatcher", "yellow warbler"))
waterfowl_enc_rate <- ID_enc_rate %>%
filter(common.name %in% c("American coot", "American wigeon",
"cinnamon teal", "common goldeneye", "common merganser",
"mallard", "ring-necked duck", "western grebe"))6 Identify the correct chunk commands to use in different situations.
What do the chunk commands do:
7 Set up a chunk’s outputs correctly.
We use code chunk arguments from the knitr package to choose the parts of our code chunks that are outputted in the final html document.
Code chunk arguments:
- include = FALSE hides code and results from the output document (html in our case), but code will still run
- eval = FALSE to include code in the document without running it
- echo = FALSE hides code but not results from the document
- results = ‘hide’ hides results but not the code from the document
- warning, message, error = FALSE hides warnings, messages, and error messages from the document
7.0.1 Thought Excercise:
Take 5 minutes to discuss with the person sitting next to you. Given the same chunk of analysis, how would you set up your chunk arguments when the document is being sent to your advisor for review versus being sent to a journal for publication? Then share with the class.
8 Dynamically include locally sourced modular analysis
For eval and echo, you can tell knitr which expressions in the chunk to include using numerical vectors. For example, eval = 1:2 will only include the 1st 2 expressions of code in the output document.
9 Dynamically report variables in your text.
Sometimes you may want to have R code or output appear inline with the rest of the markdown document. These can be static or dynamic.
- Static: When you want to display a line of code in the markdown document.
- Example: Here is a line of code from data prep for this lesson:
ID_enc_rate <- state_enc_rate_clean_filtered %>% filter(encounter.state.normalized!=0 )
- Example: Here is a line of code from data prep for this lesson:
- Dynamic: When you want to display output of a line of code inline with the rest of the markdown document.
- Example: The average encounter rate for the most commonly encountered passerines in Idaho is 69.2773162.
10 Source or code analysis through multiple methods.
We will go over three ways to include analysis in your R Markdown document: locally sourced modular analysis, url-sourced modular analysis, and using a code chunk. We will also go over the scenarios in which you might use each method.
10.1 Locally sourced modular analysis
You may have previously written code locally stored on your computer that you want to pull for an analysis. To do so, we will save that code in its own R file and use the source command from knitR to call it. This is most helpful in the early stages of your research, as this is not the best practice for ensuring reproducible science.
Use the argument include = FALSE to run the analysis and produce objects that can still be used by other code chunks but will not show up in the output document.
make a separate r file that calculates means of passerine encounter rates, then source it here.
10.2 Url-sourced modular analysis
Once you are further along in your research, you may want to make sure your file in publicly accessible to ensure reproducibility. You can host your file in a GitHub repository and use the source_url command from the devtools package to call it.
We have set up a pre-made GitHub file for this section.
source from pre-made github file. pre-made file on shorebird encounter rate means
10.3 Analyze data within a code chunk
Lastly, the simplest way to include analysis is to analyze the data within a code chunk. This is the best method for reproducibility as all your analysis is in one document, making it easier for other to reuse your code.
For this tutorial, we will create a code chunk with a simple analysis that will generate a figure comparing encounter rates between Idaho and Sonora.
10.3.1 Challenge:
What code chunk arguments should we use if we want to figure to show up in the output document but not the code?
Create figure comparing encounter rates between idaho and sonora. Ask students what the code chunk arguments should be.
11 Ensure results are reproducibly random
When an analysis produces simulations, a random number generator is generally used so that others can replicate your results. For this tutorial, we will do an exercise to learn the importance of using the set.seed command to ensure replicability.
11.0.1 Exercise:
You and the person next to you use the same distribution variables but diff vs. same set.seed. Do you get the same result? What about when you use the same set.seed? Insert set.seeds here.
# Set seed as 125
set.seed(125)
# Draw 1000 numbers
Draw2 <- rnorm(1000, mean = 0, sd = 2) # Summarize Draw1
# Draw 1000 other numbers
Draw1 <- rnorm(1000, mean = 5, sd = 1.5)
summary(Draw2)## Min. 1st Qu. Median Mean 3rd Qu. Max.
## -7.2112 -1.4071 -0.1040 -0.1215 1.3155 5.6772plot(Draw2)
plot(Draw1)
model <- lm(Draw1 ~ Draw2)
plot(model)
# Set seed as 150
set.seed(150)
# Draw 1000 numbers
Draw3 <- rnorm(1000, mean = 0, sd = 2) # Summarize Draw1
# Draw 1000 other numbers
Draw4 <- rnorm(1000, mean = 5, sd = 1.5)
summary(Draw2)## Min. 1st Qu. Median Mean 3rd Qu. Max.
## -7.2112 -1.4071 -0.1040 -0.1215 1.3155 5.6772plot(Draw2)
plot(Draw1)